home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 10928 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.0 KB

  1. Path: cliffy.lfwc.lockheed.com!news
  2. From: Ken Garlington <GarlingtonKE@lfwc.lockheed.com>
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++
  4. Subject: Re: C/C++ knocks the crap out of Ada
  5. Date: Mon, 11 Mar 1996 13:54:30 +0000
  6. Organization: Lockheed Martin Tactical Aircraft Systems
  7. Message-ID: <31443096.225@lfwc.lockheed.com>
  8. References: <00001a73+00002504@msn.com> <4h5hgj$vpd@tomquartz.niestu.com> <4h7jskINNnph@anvil.ugrad.cs.ubc.ca> <313EDF38.61C1@lfwc.lockheed.com> <4hpoth$6uo@sun152.spd.dsccc.com>
  9. NNTP-Posting-Host: cliffy.lfwc.lockheed.com
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 2.0 (Macintosh; I; 68K)
  14.  
  15. Kevin Cline wrote:
  16. > Ken Garlington  <GarlingtonKE@lfwc.lockheed.com> wrote:
  17. >  >Kazimir Kylheku wrote:
  18. >  >> I bet I could get a Fortran programmer to write Ada code that
  19. >  >> looks like Ada but is really Fortran in disguise. :)
  20. >  >
  21. >  >Except - it would not have the aliasing errors of FORTRAN common blocks,
  22. >  >for example.
  23. > That is a very old Fortran programmer error, virtually eliminated when the
  24. > INCLUDE statement became widely supported and it was easy to ensure that
  25. > all modules had consistent COMMON block definitions.
  26.  
  27. Actually, you can get bit by the INCLUDE as well, since you can compile different
  28. references at different times. If the included file changes in between....
  29. Not a problem with Ada, due to the compilation order checks.
  30.  
  31. Nonetheless, taking a program written in FORTRAN and converting it to Ada
  32. provides benefits, even if you don't restructure the program.
  33.  
  34. > The modern Fortran programmer using Ada would put all the data in
  35. > a package named 'GLOBALS'.  There would be no aliasing problems, but
  36. > huge problems due to lack of encapsulation.
  37.  
  38. Certainly, a poorly-designed program can be worse than a well-designed program.
  39. I can't argue otherwise. However, as your own statement points out, a
  40. poorly-designed program in Ada is often better than a poorly-designed program in
  41. FORTRAN. Which was my point.
  42.